-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a Dynamic Scene From a Query Filter #6004
Create a Dynamic Scene From a Query Filter #6004
Conversation
/// filter provided. All components that impl `Reflect` will be included. | ||
pub fn from_query_filter<F>(world: &mut World) -> Self | ||
where | ||
F: ReadOnlyWorldQuery + 'static, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an interesting bound; we don't require ReadOnlyWorldQuery
on the F
in Query<Q, F>
. Perhaps we should though?
I don't think creating a scene from a query filter is a good api. I would prefer to have an api like in #6013 to extract part of the world from a scene and a root, mainly because:
|
I don't know that much about the implementation issues you are describing. But I think this could be a useful feature. I could imagine myself making a savable component or something similar. Then I would just update my save file using a filter for anything with that component. |
So, this seems like a reasonable solution! There are two problems here, that Francois is attempting to point out:
I think the first needs to be fixed in some form, but the second can be cautioned against. |
let mut query = world.query_filtered::<Entity, F>(); | ||
|
||
let type_registry = world | ||
.get_resource::<AppTypeRegistry>() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO we should probably force users to pass in this type explicitly, in order to clarify which type registry they want to use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't there just be one type registry per world? Or per app? How could there be multiple?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh I see whats going on.
In order for a component to be saved to a scene, it needs to be registered in the type registry. If a user tried to use this method without registering their types first, then the scene would not be created with that component on it.
The type registry works actually as a filter of which component you can extract, but unlike a There is one built in in the main world with all registered components, but building one with just the components is easy, see the second example in #6013. The API proposed in this PR is pretty much equivalent to https://docs.rs/bevy/latest/bevy/prelude/struct.DynamicScene.html#method.from_world. Rather than specify a This proposed API: DynamicScene::from_query_filter::<(With<ComponentA>, With<ComponentB>)>(&mut world); What already exist in Bevy: let mut atr = AppTypeRegistry::default();
atr.write().register::<ComponentA>();
atr.write().register::<ComponentB>();
DynamicScene::from_world(&world); The current API is a little more verbose, but you can't specify an invalid filter with it. |
Never mind my comment above, I rechecked the doc you wrote. Your PR extracts all components, but only for entities in the filter 👍 Then adding a type registry would allow you to chose which components to extract |
Closed in favor of #6227. |
# Objective - make it easier to build dynamic scenes ## Solution - add a builder to create a dynamic scene from a world. it can extract an entity or an iterator of entities - alternative to #6013, leaving the "hierarchy iteration" part to #6185 which does it better - alternative to #6004 - using a builder makes it easier to chain several extractions
# Objective - make it easier to build dynamic scenes ## Solution - add a builder to create a dynamic scene from a world. it can extract an entity or an iterator of entities - alternative to bevyengine#6013, leaving the "hierarchy iteration" part to bevyengine#6185 which does it better - alternative to bevyengine#6004 - using a builder makes it easier to chain several extractions
# Objective - make it easier to build dynamic scenes ## Solution - add a builder to create a dynamic scene from a world. it can extract an entity or an iterator of entities - alternative to bevyengine#6013, leaving the "hierarchy iteration" part to bevyengine#6185 which does it better - alternative to bevyengine#6004 - using a builder makes it easier to chain several extractions
# Objective - make it easier to build dynamic scenes ## Solution - add a builder to create a dynamic scene from a world. it can extract an entity or an iterator of entities - alternative to bevyengine#6013, leaving the "hierarchy iteration" part to bevyengine#6185 which does it better - alternative to bevyengine#6004 - using a builder makes it easier to chain several extractions
# Objective - make it easier to build dynamic scenes ## Solution - add a builder to create a dynamic scene from a world. it can extract an entity or an iterator of entities - alternative to bevyengine#6013, leaving the "hierarchy iteration" part to bevyengine#6185 which does it better - alternative to bevyengine#6004 - using a builder makes it easier to chain several extractions
Objective
This PR copies over the
scene_from_query_components
function fromiyes_scene_tools
. I am not the author of that code I am merely copying it over.This allows users to do something like...
This is my first Bevy PR!